Git Kata 8: Repository Forking and Pull Requests

The Coders have a son, Cody. A responsible young lad, Cody has just turned sixteen years old and now has his driver’s license. Cody has volunteered to take on some new responsibilities to go with his new freedom: shopping and managing the grocery list.

Cody is also an aspiring developer and engineer. Cody has been studying CI/CD. His first act as manager of the grocery list is to propose a new workflow for adding items to the Next Visit list.

Cody is going to take ownership of the web-storelist repository, hosted in Gogs, from the devops administrator user. Cody will then grant Ken and Carrie read access to web-storelist. Ken and Carrie will create a fork of web-storelist and commit their changes to the fork. Finally, they will request their changes be merged into Cody’s authoritative repository using pull requests. This workflow will allow Cody to control the changes flowing into his repository, which will be the entry point to the CI pipeline we’ll build with the Jenkins katas.

Step 1: Create Cody’s account in Gogs#

The following are the steps to create Cody’s account in Gogs:

• Switch to URL and select the tab with Gogs open.
• Select “Admin Panel” from the top-right drop-down.
• Create a new user with the following details:
  • Username: “cody.coder”
  • Email: “cody@thecoders.com”
  • Password: “katas”

Cody’s first step is to log in to Gogs with the DevOps account (the administrator account) and create an account for himself.

Step 2: Transfer the “web-storelist” repository to Cody#

The following are the steps to transfer the “web-storelist” repository to Cody:

• Click “Dashboard” from the top navigation.
• Select the “web-storelist” repository from “My Repositories.”
• Click “Settings.”
• Scroll down to the “Danger Zone.”
• Transfer the “web-storelist” repository to Cody.

Cody now has his account created, and the “web-storelist” repository ownership is transferred to him.

• To protect the main branch of “web-storelist,” we need to do the following:

  • Click the “Settings” button at the top-right.
  • Click “Branches” in the left navigation.
  • Select the “main” branch under “Protected Branches.”
  • Check “Protect this branch.”
  • Click “Update Settings.”

Cody has protected the main branch. This will prevent users from using the --force parameter when pushing commits.

To grant read access to the repository:

• Log out of Gogs.
• Login as Cody (“cody.coder/katas”).
• Select “web-storelist” under “My Repositories.”
• Click “Settings.”
• Click “Collaboration.”
• Set Ken and Carrie’s accounts to “Read.”

Cody has now granted Mom and Dad read-only access to the main branch. They will be able to execute git pull to get the latest commits, but they will no longer be able to use git push to push commits directly to main in Cody’s web-storelist repository.

Step 3: Log in as Ken and create a fork#

Ken and Carrie will now make their commits into forks of Cody’s web-storelist repository. A fork is a copy of a repository usually owned by the creator of the fork. Forks allow developers to experiment with code changes to a project in a separate repository.

When they’re ready, Ken and Carrie can push commits to their forks and then submit a pull request to Cody. A pull request contains commits that a contributor wants to be merged into the primary, authoritative repository. Cody will review the pull requests to ensure that the items are valid and in the correct order. If everything looks good, he can accept the pull request. Accepting a pull request merges its commits from the fork into the main branch of his repository.

To create a fork of “web-storelist” as Ken, we need to do the following:

• Sign out of Gogs.
• Sign in as Ken.
• Select the “web-storelist” repository under “Collaborative Repositories.”
• Click the “Fork” button.
• Click “Fork Repository.”

Ken creates his fork of Cody’s repository. He can do this because he has read access to Cody’s web-storelist repository.

To clone Ken’s fork:

• Return to Ken’s terminal window.

In this step, Ken clones his fork locally so he can make edits to the files and commit them to his own fork. The new local clone is pulled to the ken_fork directory.

The commands to open, edit, and save the file are given below.

• Add another item to the Next Visit list.
• Save the file.

Ken adds an item to the Next Visit list from the Main List.

To commit the changes, return to Ken’s terminal window.

Ken stages and commits the change he just made to storelist.htm to the kens_list branch of his local repository.

The command to push the changes is given below.

• Username: “ken.coder”
• Password: “katas”

Ken pushes the change to his fork on the Gogs server. He’s now ready to submit his pull request.

To create a pull request in Cody’s repository, we need to do the following:

• Return to Gogs.
• Select “Dashboard” in the top navigation.
• Select the “web-storelist” repository under “Collaborative Repositories.”
• Click the “Pull Requests” link.
• Add a title and a comment.
• Click “Create Pull Request.”

Gogs automatically compares the main branch in Ken’s fork to the main branch in Cody’s repository. We can scroll down to see a visual comparison of the differences between storelist.htm in their respective repositories.

Ken doesn’t have write access to Cody’s repository, so he can’t accept the pull request. Cody will do that in the next step.

Step 4: Review the pull request as Cody and accept#

The following are the steps to review the pull request as Cody and accept it:

• Sign out of Gogs.
• Sign in as Cody.
• Select the “web-storelist” repository under “My Repositories.”
• Click the “Pull Requests” link.
• Select the pull request.
• Click the “Merge Pull Request” button.

Cody logs into Gogs and sees that a pull request is waiting for him to review. He selects the pull request and reviews the proposed changes from Ken. Everything looks good, so he accepts the pull request. Ken’s changes are now merged into the authoritative web-storelist repository.

Pull requests are used by project administrators as a method to review changes before they’re merged. Administrators review code for quality and other acceptance criteria. Changes that are accepted become part of the released product. The build and release of software products are automated through CI.